home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxxx / rfc1139 < prev    next >
Text File  |  1995-07-25  |  14KB  |  339 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                             IETF-OSI Working Group
  8. Request for Comments: 1139                                     R. Hagens
  9.                                                             January 1990
  10.  
  11.  
  12.                      An Echo Function for ISO 8473
  13.  
  14. Status of this Memo
  15.  
  16.    This memo defines an echo function for the connection-less network
  17.    layer protocol.  This memo is not intended to compete with an ISO
  18.    standard.  This is a Proposed Elective Standard for the Internet.
  19.    Distribution of this memo is unlimited.
  20.  
  21. Abstract
  22.  
  23.    This memo defines an echo function for the connection-less network
  24.    layer protocol.  Two mechanisms are introduced that may be used to
  25.    implement the echo function.  The first mechanism is recommended as
  26.    an interim solution for the Internet community.  The second mechanism
  27.    will be progressed to the ANSI X3S3.3 working group for consideration
  28.    as a work item.
  29.  
  30.    When an ISO standard is adopted that provides functionality similar
  31.    to that described by this memo, then this memo will become obsolete
  32.    and superceded by the ISO standard.
  33.  
  34. 1.  Introduction
  35.  
  36.    The OSI Connection-less network layer protocol (ISO 8473) defines a
  37.    means for transmitting and relaying data and error report PDUs
  38.    through an OSI internet.  Unfortunately, the world that these packets
  39.    travel through is imperfect.  Gateways and links may fail.  This memo
  40.    defines an echo function to be used in the debugging and testing of
  41.    the OSI network layer.
  42.  
  43.    Network management protocols can be used to determine the state of a
  44.    gateway or link.  However, since these protocols themselves utilize a
  45.    protocol that may experience packet loss, it cannot be guaranteed
  46.    that the network management applications can be utilized.  A simple
  47.    mechanism in the network layer is required so that systems can be
  48.    probed to determine if the lowest levels of the networking software
  49.    are operating correctly.  This mechanism is not intended to compete
  50.    with or replace network management; rather it should be viewed as an
  51.    addition to the facilities offered by network management.
  52.  
  53.    There are three important issues to consider when defining an echo
  54.    extension to ISO 8473: complexity, code-path divergence, and backward
  55.  
  56.  
  57.  
  58. IETF-OSI Working Group                                          [Page 1]
  59.  
  60. RFC 1139             An Echo Function for ISO 8473          January 1990
  61.  
  62.  
  63.    compatibility.  The complexity of the echo facility must be kept low.
  64.    If it is not, then there is a good chance that the facility will not
  65.    be universally provided.  The code-path consideration requires that
  66.    the echo path through a system is identical (or very close) to the
  67.    path used by normal data.  An echo path must succeed and fail in
  68.    unison with the normal data path or else it will not provide a useful
  69.    diagnostic tool.
  70.  
  71.    Backward compatibility is an important consideration whenever a
  72.    change is made to a protocol.  For this reason, this memo defines two
  73.    implementation mechanisms: the short term approach and the long term
  74.    approach.  The short term approach will produce echo packets that are
  75.    indistinguishable from normal data ISO 8473 PDUs.  These echo packets
  76.    may be switched through ISO 8473 routers that do not implement the
  77.    echo function.  The short term approach will be adopted as an
  78.    Elective Internet Standard because it is backward compatible with ISO
  79.    8473.  However, due to its nature, the short term approach will never
  80.    be incorporated into future versions of ISO 8473.
  81.  
  82.    The long term approach will produce echo packets that are not
  83.    compatible with the existing standard.  However, the long term
  84.    approach may be acceptable by ISO as an addendum to ISO 8473.  In
  85.    this event, backward compatibility will no longer be an issue.  At
  86.    that juncture, the short term approach defined by this memo will be
  87.    obsolete and superseded by the ISO addendum.
  88.  
  89. 2.  The Generic Echo Function
  90.  
  91.    The following section will describe the echo function in a generic
  92.    fashion.  This memo defines an echo-request entity.  The function of
  93.    the echo-request entity is to accept an incoming echo-request PDU,
  94.    perform some processing, and generate an echo-reply PDU.  Depending
  95.    on the echo implementation, the echo-request entity may be thought of
  96.    as an entity that exists above the network layer, or as an entity
  97.    that co-exists with the network layer.  Subsequent sections will
  98.    detail the short and long term implementation mechanisms.
  99.  
  100.    For the purposes of this memo, the term "ping" shall be used to mean
  101.    the act of transmitting an echo-request PDU to a remote system (with
  102.    the expectation that an echo-reply PDU will be sent back to the
  103.    transmitter).
  104.  
  105.    2.1  The Echo Request
  106.  
  107.       When a system decides to ping a remote system, an echo-request is
  108.       built.  All fields of the PDU header are assigned normal values
  109.       (see implementation specific sections for more information).  The
  110.       address of the system to be pinged is inserted as the destination
  111.  
  112.  
  113.  
  114. IETF-OSI Working Group                                          [Page 2]
  115.  
  116. RFC 1139             An Echo Function for ISO 8473          January 1990
  117.  
  118.  
  119.       NSAP address.  The rules of segmentation defined for a DT PDU also
  120.       apply to the echo-request PDU.
  121.  
  122.       The echo-request is switched through the network toward its
  123.       destination.  Upon reaching the destination system, the PDU is
  124.       processed according to normal processing rules.  At the end of the
  125.       input processing, the echo-request PDU is delivered to the echo-
  126.       request entity.
  127.  
  128.       The echo-request entity will build and dispatch the echo-reply
  129.       PDU.  This is a new PDU.  Except as noted below, this second PDU
  130.       is built using the normal construction procedures.  The
  131.       destination address of the echo-reply PDU is taken from the source
  132.       address of the echo-request PDU.  Most options present in the
  133.       echo-request PDU are copied into the echo-reply PDU (see
  134.       implementation notes for more information).
  135.  
  136.    2.2  The Echo Reply
  137.  
  138.       The entire echo-request PDU is included in the data portion of the
  139.       echo-reply PDU.  This includes the echo-request PDU header as well
  140.       as the any data that accompanies the echo-request PDU.  The entire
  141.       echo-request PDU is included in the echo-reply so that fields such
  142.       as the echo-request lifetime may be examined when the reply is
  143.       received.  After the echo-reply PDU is built, it is transmitted
  144.       toward the new destination (the original source of the echo-
  145.       request).  The rules of segmentation defined for a DT PDU also
  146.       apply to the echo-reply PDU.
  147.  
  148.       The echo-reply PDU is relayed through the network toward its
  149.       destination.  Upon reaching its destination, it is processed by
  150.       the PDU input function and delivered to the entity that created
  151.       the echo-request.
  152.  
  153. 3.  The Short Term Implementation Mechanism
  154.  
  155.    The short term implementation mechanism  will use an ISO 8473 normal
  156.    data PDU as the echo-request and echo-reply PDU.  A special NSAP
  157.    selector value will be used to identify the echo-request and insure
  158.    that it reaches the echo-request entity.  This selector value is
  159.    known as the echo-request selector.  In addition, an echo-reply
  160.    selector is defined so that the echo-reply PDU may be identified at
  161.    the destination system.  It is important to note that (except for the
  162.    NSAP selector) the echo-request PDU and the echo-reply PDU are
  163.    indistinguishable from a DT PDU.
  164.  
  165.    This approach has the advantage that it is simple and does not allow
  166.    any code-path divergence.  In addition, this approach requires that
  167.  
  168.  
  169.  
  170. IETF-OSI Working Group                                          [Page 3]
  171.  
  172. RFC 1139             An Echo Function for ISO 8473          January 1990
  173.  
  174.  
  175.    only the systems which wish to generate an echo-reply PDU must
  176.    change.  Systems that do not adhere to this memo will not generate an
  177.    echo-reply PDU, but will still switch other echo-request and echo-
  178.    reply PDUs.
  179.  
  180.    3.1  The Echo Request
  181.  
  182.       An echo-request is built using the normal DT PDU construction
  183.       procedures.  All fields of the PDU header are assigned normal
  184.       values (see implementation notes).  The address of the system to
  185.       be pinged is inserted as the destination NSAP address.  The
  186.       selector field of the destination NSAP address must contain the
  187.       echo-request selector.  The selector field of the source NSAP
  188.       address must contain the echo-reply selector.
  189.  
  190.    3.2  The Echo Reply
  191.  
  192.       Except as noted below (see implementation notes), an echo-reply is
  193.       built using the normal DT PDU construction procedures.  The
  194.       destination NSAP address is taken from the source address of the
  195.       echo-request PDU.
  196.  
  197.    3.3  Use of NSAP Selectors
  198.  
  199.       The choice of echo-request and echo-reply NSAP selectors is a
  200.       local matter.  However, to insure interoperability, and as an
  201.       interim measure until use of the directory service becomes
  202.       widespread, this memo will recommend the following default values
  203.       (specified in decimal):
  204.  
  205.          Echo Request Selector - 30
  206.          Echo Reply Selector - 31
  207.  
  208. 4.  The Long Term Implementation Mechanism
  209.  
  210.    The long term implementation mechanism will define two new 8473 PDU
  211.    types: ERQ (echo-request) and ERP (echo-reply).  With the exception
  212.    of a new type code, these PDUs will be identical to the DT PDU in
  213.    every respect.
  214.  
  215.    4.1  The Echo Request
  216.  
  217.       The type code for the ERQ PDU is decimal 30.
  218.  
  219.    4.2  The Echo Reply
  220.  
  221.       The type code for the ERP PDU is decimal 31.
  222.  
  223.  
  224.  
  225.  
  226. IETF-OSI Working Group                                          [Page 4]
  227.  
  228. RFC 1139             An Echo Function for ISO 8473          January 1990
  229.  
  230.  
  231. 5.  Implementation Notes
  232.  
  233.    The following notes are an integral part of memo.  It is important
  234.    that implementors take heed of these points.
  235.  
  236.    5.1  Discarding PDUs
  237.  
  238.       The rules used for discarding a DT PDU (8473, sec 6.9 - sec 6.10)
  239.       are applied when an echo-request or echo-reply is discarded.
  240.  
  241.    5.2  Error Report Flag
  242.  
  243.       The error report flag may be set on the echo-request PDU, the
  244.       echo-reply PDU, or both.  If an echo-request is discarded, the
  245.       associated ER PDU will be sent to the echo-request source address
  246.       on the originating machine.  If an echo-reply is discarded, the
  247.       associated ER PDU will be sent to the echo-reply source address.
  248.       In general, this will be the address of the echo-request entity.
  249.       It should be noted that the echo-request entity and the originator
  250.       of the echo-request PDU are not required to process ER PDUs.
  251.  
  252.    5.3  Use of the Lifetime Field
  253.  
  254.       The lifetime field of the echo-request and echo-reply PDU should
  255.       be set to the value normally used for a DT PDU.  Note: although
  256.       this memo does not prohibit the generation of a PDU with a
  257.       smaller-than-normal lifetime field, this memo explicitly does not
  258.       attempt to define a mechanism for varying the lifetime field set
  259.       in the echo-reply PDU.  This memo recommends that the normal DT
  260.       lifetime value should be set in the echo-request and echo-reply
  261.       PDU.
  262.  
  263.    5.4  Transfer of Options from the echo-request
  264.         PDU to the echo-reply PDU
  265.  
  266.       With two exceptions, all options present in the echo-request
  267.       header are copied directly into the echo-reply header.  The two
  268.       exceptions are the record route option and the source route
  269.       option.  A record route option present in an echo-request PDU is
  270.       copied into the echo-reply PDU, but the routes recorded in the
  271.       option are "erased" by resetting the second octet of the option to
  272.       3.  This allows the entire record route option space to be used by
  273.       the echo-reply PDU.  Note: the record route present on the echo-
  274.       request is not lost because the echo-request PDU is wholly
  275.       contained in the data part of the echo-reply PDU.
  276.  
  277.       The second exception concerns the source route option.  A source
  278.       route option present on the echo-request PDU is not copied into
  279.  
  280.  
  281.  
  282. IETF-OSI Working Group                                          [Page 5]
  283.  
  284. RFC 1139             An Echo Function for ISO 8473          January 1990
  285.  
  286.  
  287.       the echo-reply PDU.
  288.  
  289.    5.5  Use of the Priority Option
  290.  
  291.       If the priority option is included, it will normally be set to
  292.       value 0 (default priority).  This memo allows for priority values
  293.       higher than 0 to be set in the echo-request or echo-reply header,
  294.       but cautions against this practice.
  295.  
  296.    5.6  Use of the Source Route Option
  297.  
  298.       Use of the source route option in ISO 8473 may cause packets to
  299.       loop until their lifetime expires.  For this reason, this memo
  300.       recommends against the use of the source route option in either an
  301.       echo-request or echo-reply PDU.  If the source route option is
  302.       used to specify the route that the echo-request PDU takes toward
  303.       its destination, this memo does not recommend the use of an
  304.       automatically generated source route on the echo-reply PDU.
  305.  
  306.    5.7  Transmission of Multiple Echo Requests
  307.  
  308.       The echo function may be utilized by more than one process on any
  309.       individual machine.  The mechanism by which multiple echo-requests
  310.       and echo-replies are correlated between multiple processes on a
  311.       single machine is a local matter and not defined by this memo.
  312.  
  313. Security Considerations
  314.  
  315.    Security issues are not addressed in this memo.
  316.  
  317. Author's Address
  318.  
  319.    Robert A. Hagens
  320.    Computer Science Department
  321.    1210 West Dayton Street
  322.    Madison, WI  53706
  323.  
  324.    Phone: (608) 262-1204
  325.  
  326.    EMail:  hagens@CS.WISC.EDU
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. IETF-OSI Working Group                                          [Page 6]
  339.